I'm just testing this PR and, for me, the border color panel doesn't add the border color inline style to the root element. The has-{color}-border-color class is present however.

The result is that the border color doesn't change when I select a new border color.

Strangely, changing the text color modifies the border color, though I can't see why in the computed styles.

If I change this line to color: colorObject?.color || value, it works as I'd expect.

Is there a reason why the style prop should be undefined here in the presence of colorObject?.slug?

Or are there CSS definitions for .has-{color}-border-color classes that I'm not seeing (or something else I'm missing)?

Thanks!

There's a good chance I missed something here so I'll look into it. Thanks for testing.

Is there a reason why the style prop should be undefined here?

This was undefined so that when using a named color it uses the CSS classes generated for the color from the current palette. If it stored the color value there the inline style overrules it. This could become a problem if the theme changes the color palette or the user switches themes.

Strangely, changing the text color modifies the border color, though I can't see why in the computed styles.

I have the suspicion that the theme sets the border color to the currentColor which would be determined by the text color. The inline border style works for me when a border style is set though.

This was undefined so that when using a named color it uses the CSS classes generated for the color from the current palette.

Thanks, that's what I suspected, was just scratching my head as to where those CSS class definitions were being (or should be) generated.

Thanks for the clarification. Just dropping here to add that I had the TwentyTwentyOne theme activated.

I could see the expected behaviour after switching to TT1 Blocks.

@nosolosw would you be able to point me in the right direction for getting the color styles generated from the theme.json color palette available for themes such as TwentyTwenty?

I believe the active theme currently has to satisfy this check before the necessary styles are included.

useEditorFeature( 'color.palette' ) will have the color palette, whether or not the theme has support for theme.json

The issue I'm trying to solve here is some older themes don't qualify to have the named color CSS classes included. In other words they are missing has-<color>-border-color.

If the TT1 Blocks or TwentyTwenty Blocks themes are active, they get the generated color classes fine. Something older such as the TwentyTwenty (non block based) theme doesn't get these so while the block has the correct CSS class on the frontend the CSS class doesn't exist in the stylesheet.

Ah, I see. Themes that don't support theme.json won't have the preset classes automatically enqueued for them, they add them themselves. At some point in the past, we experimented with enqueuing the classes for these themes as well but heard reports that this wasn't expected, so we stopped doing it.

What I see is that named border-color classes are properly attached to the block (for any theme), and that's the only thing relevant for the hook. In terms of the global stylesheet, I also see them generated and enqueued in the embedded stylesheet global-styles-inline-css for themes with theme.json support, so everything is working as expected.

One thing we should do is to add this as a dev note saying: there's this new property so themes need to enqueue the classes for the border-colors as well. Only if this feature becomes stable for 5.8. I'll add the label so we can find them later.

Also ccing a few theme people FYI (re: has-<color>-border-color classes) ― @carolinan @aristath @scruffian @MaggieCabrera

Thanks for the explanation. That helps my understanding 👍